Shouldn't this only care if the current room is being indexed/yet to be indexed if the search kind is room rather than all?

You're right, and it's a live false positive rather than a hypothetical.

useIsCrawlInProgress keyed off index.currentRoom() !== null, which is global: currentRoom() returns null only when currentCheckpoint === null and the whole checkpoint queue is empty. So searching a fully-crawled room showed "results may be incomplete" purely because the crawler happened to be grinding through an unrelated room — for the entire initial crawl. That's cry-wolf on a banner whose only job is to be believed, and it's at odds with #32253 itself, which is framed around "the conversation I am looking at".

One note on the props, since it changes the shape of the fix: the kind this is anchored to is WarningKind { Files, Search } — files-panel vs search-panel, not room-vs-all. The room/all dimension is SearchScope, which wasn't plumbed into this component. So it needed a new prop rather than a re-read of kind; the two are orthogonal and I've kept both.

Now pushed. RoomSearchAuxPanel already computed scope twenty lines above the render and already had searchInfo.roomId, so it's two optional props each side — no changes to RoomView, SearchInfo, or FilePanel. SearchScope.Room → crawlingRooms.has(roomId), otherwise crawlingRooms.size > 0.

Three things worth flagging:

I moved the all-rooms branch onto crawlingRooms() too, rather than leaving it on currentRoom(). That's slightly beyond what you asked. The reason: currentRoom() returns client.getRoom(roomId), which is null if the js-sdk doesn't know the head-of-queue room (e.g. a checkpoint persisted for a room you've since left) — so it can also fail to warn while your room sits queued behind it. crawlingRooms() works on raw room ids and is immune. Happy to revert that half if you'd rather keep the All path untouched.

Seshat can't actually tell us whether a room is fully indexed. isRoomIndexed() looks like the right call but is presence-only — "the index contains events for the given room", i.e. ≥1 event. So "has an outstanding checkpoint" via crawlingRooms() is the closest honest signal, and absence from that set isn't proof of completeness (no back-pagination token, checkpoint dropped on a 403, or pre-seeding all look identical to "done"). That means this narrows false positives without fixing under-reporting. The blind spot exists today too, so I've documented it on the hook rather than papered over it — but it's why I've softened Fixes #32253 to Part of: the issue's other ask (prioritise the open conversation for indexing) is a crawler-ordering change I haven't attempted.

changedCheckpoint only carries currentRoom(), so the payload can't answer a per-room question — the handler ignores the argument and re-reads the set, same as ManageEventIndexDialog. There's a test pinning exactly that (payload names a different room, searched room still queued → still warns).

No string or markup change, so the design sign-off should still hold.

At least based on the jsdoc of this method it doesn't sound like it will be all uncrawled rooms, just rooms which are currently being crawled, no? Maybe combining the check with isRoomIndexed would be better. I.e room is not in crawlingRooms && isRoomIndexed(room)

though then also worth updating the callback name

On the first half, though, crawlingRooms() is broader than its jsdoc suggests, and I think the doc is what misled you. It adds every queued checkpoint, not just the one in flight:

this.crawlerCheckpoints.forEach((checkpoint) => {
    crawlingRooms.add(checkpoint.roomId);
});
if (this.currentCheckpoint !== null) {
    crawlingRooms.add(this.currentCheckpoint.roomId);
}

crawlerCheckpoints is the pending queue, so a room sitting fifth in line is already in the set — it does cover "yet to be indexed", just not under that name. The inline doc on the return type says "The rooms that we are currently crawling", which reads as current-only. I've reworded it to "the rooms with an outstanding crawler checkpoint: the one being crawled right now, and those still queued behind it" — one line in EventIndex.ts, since it caused the misread and would cause the next one. Happy to drop it if you'd rather keep this PR to two files.

Your suggestion still closes a real gap, so I've taken it. What the crawl set genuinely can't see is a room with no checkpoint at all — before addInitialCheckpoints() seeds them, such a room is absent from the set and looks identical to "done". That's the issue's own repro ("log into a new desktop session"), which the previous version would have sat silent through. So room-scoped is now has(roomId) || !isRoomIndexed(roomId), i.e. your not in crawlingRooms && isRoomIndexed(room) inverted.

One wrinkle I hit implementing it, which changed the shape slightly. isRoomIndexed has no change notification: changedCheckpoint is the only event EventIndex emits, and it fires solely on checkpoint transitions inside crawlerFunc — adding events to the index emits nothing, and an idle crawler is silent (crawlerCheckpoints.shift() → undefined → idle = true; continue, no emit). So a warning raised purely from !isRoomIndexed once the crawler has drained would never be re-evaluated and would stick for the session.

So I only ask the isRoomIndexed question while the crawler still has work outstanding:

if (relevant || !anyOutstanding || scope !== SearchScope.Room || roomId === undefined) return;
const indexed = await index.isRoomIndexed(roomId);

That keeps the case you're pointing at (during the initial crawl, my room isn't seeded yet → warn) and drops the stuck one (crawler idle → nothing more is coming, and claiming the index is "still being built" would be untrue). It also self-clears: the crawler emits when it nulls currentCheckpoint on drain, so we get a final event to re-evaluate on. There's a test pinning it — removing the !anyOutstanding guard turns it red.

Three smaller notes:

• isRoomIndexed is presence-only, so it can't be a drop-in &&. Its contract is "the index contains events for the given room" — ≥1 event, not complete — so it's a floor ("definitely not started"), not a completeness check. I've documented it as that rather than implying more.
• It returns boolean | undefined (indexManager?.isRoomIndexed(...)); undefined means there's no manager to ask, which isn't evidence either way. So it warns on === false, not !indexed, with a test for it.
• All-rooms stays on the checkpoint set — per-room isRoomIndexed across every encrypted room would be an IPC round-trip each, per changedCheckpoint.

Renamed as you suggested: useIsCrawlInProgress → useIsIndexIncomplete. The old name described the old, narrower question. The checkpoint half stays synchronous and seeds the initial state, so the common "actively crawling" case renders without a flash; only the never-indexed refinement awaits, and the state is re-seeded from the checkpoint set on every scope/room change so a previous room's answer can't sit on screen while the lookup is in flight (also tested). A generation counter drops any response the scope has moved on from.